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DETAILED ACTION 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1,3-6,8-11,14,15,1 7-20, 22-25, 27 and 28 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ogawa et al. (Design and implementation of 
DV based video over RTP. Proc. Packet Video2000, 2000), hereinafter Ogawa and in 
view of Andandakumar et al. (US PAT PUB 2004/0252701 , hereinafter Anandakumar) 
and Craft et al. (US PAT PUB 2007/0067497, hereinafter Craft). 

Regarding claim 1, Ogawa teaches a Packet processing apparatus, and packet 
processing method comprising: a. a packetizing one or more data streams into 
isochronous data packets; b. encapsulating one or more isochronous data packets 
according to a real- time transport protocol to form a real-time transport protocol data 
packet; and c. sending the real-time transport protocol data packets from a transmitting 
device to a receiving device over a non-isochronous compliant network (sections 4-4.1, 
we implemented IP based DV video transmission system called DV Transport 
System(DVTS) using DV/RTP[5][6]. The overview of the DVTS is shown in Fig. 2. The 
system consists of a Pentium based PC with FreeBSD as an operating system, 
IEEE1394 device driver and interface^], and DV/RTP stream sender and receiver 
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application. Both DV/RTP sender and receiver PC have an IEEE 1394 interface on the 
PCI bus. The camcorder connected DV/RTP sender side (Shown in the left side of Fig. 
2) creates IEEE1394 encapsulated DV packet stream. The sender application receives 
the DV stream via PCI IEEE1394 interface card, encapsulates the DV packet of 
IEEE1394 into RTP, and transmits it to the IP network. The receiver application obtains 
the IEEE1394 DV packets by reconstructing DV data received using RTP. IEEE1394 
header is attached to the reconstructed DV/IEEE1394 packet and transferred to the DV 
recorder deck via PCI IEEE1394 interface card (Shown in the right side of Fig. 2). The 
DV recorder deck displays the DV data on the connected display. The DV system we 
implemented has the advantage that the system can be configured only with highly 
available standard PCI based PC compatibles, consumer DV camcorder and DV VCR 
equipment having IEEE1394 interface. In order to use consumer DV devices equipped 
with IEEE1394 interface, we designed and implemented an IEEE1394 device driver on 
FreeBSD 3.3[7]. IEEE1394 high speed serial bus system is designed for a packet based 
shared media computer bus system. The network bandwidth is logically specified from 
100Mbps to 3.2Gbps. The goal of IEEE1394 is to integrate and observe various 
interface and cable specification into only single bus (cable) system, i.e. storage device 
interface instead of SCSI and IDE, peripheral of parallel and serial, network of ethernet, 
processor interconnect of VME and also RCA cable of audio and visual equipment. 
Heterogeneous speed devices can be connected within a single IEEE1394 physical 
network, which enables devices are made at the appropriate cost. Three types of 
transmission mode is provided by IEEE1394; 1)isochronous stream mode for QoS 
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which provides especially strict packet jitter and guaranteed bandwidth without reliable 
communication, 2) asynchronous stream for best effort without reliability, and 
3)asynchronous request for the reliable communication. Data timing in IEEE1394 is 
shown in Fig 3. Every packet transmission action is brought with 8 kHz time slice whose 
value corresponds to the fairness unit in the IEEE1394 system. The 8kHz time slice unit 
is also divided into 6144 time slot for bandwidth management. Isochronous stream 
transmission would be done by taking the number of time slot the sender requires first, 
sending a packet whose size is smaller than the time slot at every 8kHz fairness unit. 
Therefore, the packet jitter of the isochronous stream mode is suppressed in the order 
of 8kHz (125 micro second), and the condition might be enough for any jitter sensitive 
high quality packet video system. It is not easy for the legacy packet based shared 
network system to satisfy such conditions. However, every IEEE1394 LSI chip already 
supports the isochronous stream mode on its hardware level, and the cost of a chip is 
less than $20. Consumer DV adopts IEEE1394 as its digital interface standard, 
although the isochronous stream mode does not ensure reliable communication. When 
sending DV stream on IEEE1394, the 80 bytes DIF blocks are aggregated to 
appropriate size, e.g. an IEEE1 394 packet of consumer SD DV stream consists of 6 DIF 
blocks. 8 bytes common isochronous information (CIP) header is prepended to 
aggregated DV packet). Ogawa teaches the transmitting device is coupled to a first 
isochronous compliant network and the receiving device is coupled to a second 
isochronous compliant network (see figure 2). 
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Ogawa does not explicitly generating a cycle record for each isochronous cycle 
of a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network. 

Anandakumar in the same or similar field of endeavor teaches generating a cycle 
record (paragraph 0227, sampling instant) for each isochronous cycle (paragraph 0227, 
a clock oscillator in the system of FIG. 3 provides a suitably stable time base for 
calculating (i.e. generating) this sampling instant time) of a first isochronous compliant 
network, wherein each cycle record includes a relative timing marker that indicates a 
timing of the real-time transport protocol data packet relative to a cycle master of the 
first isochronous compliant network (paragraph 0227, In connection with FIG. 9, RTP is 
useful for real-time data like interactive voice and video (i.e. isochronous compliant 
network). RTP services include payload type identification, sequence number, time 
stamp, and synchronization source identifier (identifies sender and any conference 
contributors to the packet). The header includes other information, and the payload 
includes voice frames, compressed audio, video, real-time control and measurement 
data, or other real-time information. The timestamp reflects the sampling instant of the 
first byte of the first voice frame in the packet. A clock oscillator in the system of FIG. 3 
provides a suitably stable time base (i.e. a cycle master) for calculating this sampling 
instant time with sufficient accuracy to allow the delay-jitter handling block 371' and lost 
packet compensation block 381' to respond to delay, jitter, and out-of-order packets). 
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Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of generating a cycle record for each isochronous cycle of 
a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network as taught by 
Anandakumar the packet processing apparatus, and packet processing method of 
Ogawa in order tot provide necessary timing reference and guidelines for transmitting 
data to the destination device (as suggested by Anandakumar, paragraph 0227). Known 
work in one field of endeavor may prompt variations of it for use in either the same field 
or a different one based on design incentives or other market forces/market place 
incentives if the variations are predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
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real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Regarding claim 3, Ogawa teaches eaches the first isochronous compliant 
network and the second isochronous compliant network each comprise an IEEE 1394 
compliant bus architecture (see figure 2 IEEE1394 bus). 

Regarding claim 4, Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network are coupled via the non-isochronous 
compliant network (see figure 2). 

Regarding claim 5, Ogawa teaches teaches the non-isochronous compliant 
network comprises an Internet Protocol network (see figure 2). 

Regarding claim 6, Ogawa teaches teaches the Internet Protocol network 
comprises an Ethernet/Internet Protocol network (abstract). 

Regarding claim 8, Ogawa teaches the real-time transport protocol defines a 
real-time transport protocol header and a real-time transport protocol data payload for 
each real-time transport protocol data packet (see figure 1). 
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Regarding claim 9, Ogawa teaches the real-time transport protocol data payload 
comprises one or more isochronous cycle records (See Section 4.1). 

Regarding claim 10, Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 11, Ogawa teaches each isochronous data packet comprises an 
IEEE 1394 isochronous data packet (See Section 4.1). 

Regarding claim 14, Ogawa teaches each real-time transport protocol data 
packet includes at least a portion of an isochronous cycle record (See Section 4.1). 

Regarding claim 15, Ogawa discloses a an apparatus for communicating data 
strasm, that apparatus comprising: a. means for packetizing one or more data streams 
into isochronous data packets; b. means for encapsulating one or more isochronous 
data packets according to a real- time transport protocol to form a real-time transport 
protocol data packet; and c. means for sending the real-time transport protocol data 
packets from a transmitting device to a receiving device over a non-isochronous 
compliant network (sections 4-4.1, we implemented IP based DV video transmission 
system called DV Transport System(DVTS) using DV/RTP[5][6]. The overview of the 
DVTS is shown in Fig. 2. The system consists of a Pentium based PC with FreeBSD as 
an operating system, IEEE1394 device driver and interface^], and DV/RTP stream 
sender and receiver application. Both DV/RTP sender and receiver PC have an 
IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender side 
(Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet stream. 
The sender application receives the DV stream via PCI IEEE1394 interface card, 
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encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP network. 
The receiver application obtains the IEEE1394 DV packets by reconstructing DV data 
received using RTP. IEEE1394 header is attached to the reconstructed DV/IEEE1394 
packet and transferred to the DV recorder deck via PCI IEEE1394 interface card 
(Shown in the right side of Fig. 2). The DV recorder deck displays the DV data on the 
connected display. The DV system we implemented has the advantage that the system 
can be configured only with highly available standard PCI based PC compatibles, 
consumer DV camcorder and DV VCR equipment having IEEE1394 interface. In order 
to use consumer DV devices equipped with IEEE1394 interface, we designed and 
implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 high speed 
serial bus system is designed for a packet based shared media computer bus system. 
The network bandwidth is logically specified from 100Mbps to 3.2Gbps. The goal of 
IEEE1394 is to integrate and observe various interface and cable specification into only 
single bus (cable) system, i.e. storage device interface instead of SCSI and IDE, 
peripheral of parallel and serial, network of ethernet, processor interconnect of VME and 
also RCA cable of audio and visual equipment. Heterogeneous speed devices can be 
connected within a single IEEE1394 physical network, which enables devices are made 
at the appropriate cost. Three types of transmission mode is provided by IEEE1394; 
1)isochronous stream mode for QoS which provides especially strict packet jitter and 
guaranteed bandwidth without reliable communication, 2) asynchronous stream for best 
effort without reliability, and 3)asynchronous request for the reliable communication. 
Data timing in IEEE1394 is shown in Fig 3. Every packet transmission action is brought 



Application/Control Number: 10/814,848 Page 10 

Art Unit: 2476 

with 8 kHz time slice whose value corresponds to the fairness unit in the IEEE1394 
system. The 8kHz time slice unit is also divided into 6144 time slot for bandwidth 
management. Isochronous stream transmission would be done by taking the number of 
time slot the sender requires first, sending a packet whose size is smaller than the time 
slot at every 8kHz fairness unit. Therefore, the packet jitter of the isochronous stream 
mode is suppressed in the order of 8kHz (125 micro second), and the condition might 
be enough for any jitter sensitive high quality packet video system. It is not easy for the 
legacy packet based shared network system to satisfy such conditions. However, every 
IEEE1394 LSI chip already supports the isochronous stream mode on its hardware 
level, and the cost of a chip is less than $20. Consumer DV adopts IEEE1394 as its 
digital interface standard, although the isochronous stream mode does not ensure 
reliable communication. When sending DV stream on IEEE1394, the 80 bytes DIF 
blocks are aggregated to appropriate size, e.g. an IEEE1394 packet of consumer SD 
DV stream consists of 6 DIF blocks. 8 bytes common isochronous information (CIP) 
header is prepended to aggregated DV packet). Ogawa teaches the transmitting device 
is coupled to a first isochronous compliant network and the receiving device is coupled 
to a second isochronous compliant network (see figure 2). 

Ogawa does not explicitly generating a cycle record for each isochronous cycle 
of a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network. 
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Anandakumar in the same or similar field of endeavor teaches generating a cycle 
record (paragraph 0227, sampling instant) for each isochronous cycle (paragraph 0227, 
a clock oscillator in the system of FIG. 3 provides a suitably stable time base for 
calculating (i.e. generating) this sampling instant time) of a first isochronous compliant 
network, wherein each cycle record includes a relative timing marker that indicates a 
timing of the real-time transport protocol data packet relative to a cycle master of the 
first isochronous compliant network (paragraph 0227, In connection with FIG. 9, RTP is 
useful for real-time data like interactive voice and video (i.e. isochronous compliant 
network). RTP services include payload type identification, sequence number, time 
stamp, and synchronization source identifier (identifies sender and any conference 
contributors to the packet). The header includes other information, and the payload 
includes voice frames, compressed audio, video, real-time control and measurement 
data, or other real-time information. The timestamp reflects the sampling instant of the 
first byte of the first voice frame in the packet. A clock oscillator in the system of FIG. 3 
provides a suitably stable time base (i.e. a cycle master) for calculating this sampling 
instant time with sufficient accuracy to allow the delay-jitter handling block 371' and lost 
packet compensation block 381' to respond to delay, jitter, and out-of-order packets). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of generating a cycle record for each isochronous cycle of 
a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network as taught by 



Application/Control Number: 10/814,848 Page 12 

Art Unit: 2476 

Anandakumar the packet processing apparatus, and packet processing method of 
Ogawa in order tot provide necessary timing reference and guidelines for transmitting 
data to the destination device (as suggested by Anandakumar, paragraph 0227). Known 
work in one field of endeavor may prompt variations of it for use in either the same field 
or a different one based on design incentives or other market forces/market place 
incentives if the variations are predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
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may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Regarding claims 17-20, 22-25, 27 and 28, Ogawa teaches discloses all the 
limitations as discussed in the rejection of claims 1-11 and 13-14 and are therefore 
apparatus claims 17-20, 22-25, 27 and 28 are rejected using the same rationales. 

3. Claims 62, 64, 65, 68 and 69 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Ogawa et al. (Design and implementation of DV based video over 
RTP. Proc. Packet Video2000, 2000), hereinafter Ogawa and in view of Andandakumar 
et al. (US PAT PUB 2004/0252701 , hereinafter Anandakumar), Craft et al. (US PAT 
PUB 2007/0067497, hereinafter Craft) and Ben-Dor etal. (US PAT PUB 2002/0141418, 
hereinafter Ben-Dor). 

Regarding claim 62, Ogawa teaches a method of communicating data streams, 
the method comprising: a. packetizing one or more data streams into IEEE 1394 
compliant isochronous data packets; b. encapsulating one or more IEEE 1394 
compliant isochronous data packets according to a real-time transport protocol to form a 
real-time transport protocol data packet; and c. sending the real-time transport protocol 
data packets from a transmitting device to a receiving device over a non-isochronous 
compliant network (sections 4-4.1, we implemented IP based DV video transmission 
system called DV Transport System(DVTS) using DV/RTP[5][6]. The overview of the 
DVTS is shown in Fig. 2. The system consists of a Pentium based PC with FreeBSD as 
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an operating system, IEEE1394 device driver and interface^], and DV/RTP stream 
sender and receiver application. Both DV/RTP sender and receiver PC have an 
IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender side 
(Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet stream. 
The sender application receives the DV stream via PCI IEEE1394 interface card, 
encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP network. 
The receiver application obtains the IEEE1394 DV packets by reconstructing DV data 
received using RTP. IEEE1394 header is attached to the reconstructed DV/IEEE1394 
packet and transferred to the DV recorder deck via PCI IEEE1394 interface card 
(Shown in the right side of Fig. 2). The DV recorder deck displays the DV data on the 
connected display. The DV system we implemented has the advantage that the system 
can be configured only with highly available standard PCI based PC compatibles, 
consumer DV camcorder and DV VCR equipment having IEEE1394 interface. In order 
to use consumer DV devices equipped with IEEE1394 interface, we designed and 
implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 high speed 
serial bus system is designed for a packet based shared media computer bus system. 
The network bandwidth is logically specified from 100Mbps to 3.2Gbps. The goal of 
IEEE1394 is to integrate and observe various interface and cable specification into only 
single bus (cable) system, i.e. storage device interface instead of SCSI and IDE, 
peripheral of parallel and serial, network of ethernet, processor interconnect of VME and 
also RCA cable of audio and visual equipment. Heterogeneous speed devices can be 
connected within a single IEEE1394 physical network, which enables devices are made 
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at the appropriate cost. Three types of transmission mode is provided by IEEE1394; 
1)isochronous stream mode for QoS which provides especially strict packet jitter and 
guaranteed bandwidth without reliable communication, 2) asynchronous stream for best 
effort without reliability, and 3)asynchronous request for the reliable communication. 
Data timing in IEEE1394 is shown in Fig 3. Every packet transmission action is brought 
with 8 kHz time slice whose value corresponds to the fairness unit in the IEEE1394 
system. The 8kHz time slice unit is also divided into 6144 time slot for bandwidth 
management. Isochronous stream transmission would be done by taking the number of 
time slot the sender requires first, sending a packet whose size is smaller than the time 
slot at every 8kHz fairness unit. Therefore, the packet jitter of the isochronous stream 
mode is suppressed in the order of 8kHz (125 micro second), and the condition might 
be enough for any jitter sensitive high quality packet video system. It is not easy for the 
legacy packet based shared network system to satisfy such conditions. However, every 
IEEE1394 LSI chip already supports the isochronous stream mode on its hardware 
level, and the cost of a chip is less than $20. Consumer DV adopts IEEE1394 as its 
digital interface standard, although the isochronous stream mode does not ensure 
reliable communication. When sending DV stream on IEEE1394, the 80 bytes DIF 
blocks are aggregated to appropriate size, e.g. an IEEE1394 packet of consumer SD 
DV stream consists of 6 DIF blocks. 8 bytes common isochronous information (CIP) 
header is prepended to aggregated DV packet). Ogawa teaches the transmitting device 
is coupled to a first isochronous compliant network and the receiving device is coupled 
to a second isochronous compliant network (see figure 2). 
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Ogawa does not explicitly generating a cycle record for each isochronous cycle 
of a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network. 

Anandakumar in the same or similar field of endeavor teaches generating a cycle 
record (paragraph 0227, sampling instant) for each isochronous cycle (paragraph 0227, 
a clock oscillator in the system of FIG. 3 provides a suitably stable time base for 
calculating (i.e. generating) this sampling instant time) of a first isochronous compliant 
network, wherein each cycle record includes a relative timing marker that indicates a 
timing of the real-time transport protocol data packet relative to a cycle master of the 
first isochronous compliant network (paragraph 0227, In connection with FIG. 9, RTP is 
useful for real-time data like interactive voice and video (i.e. isochronous compliant 
network). RTP services include payload type identification, sequence number, time 
stamp, and synchronization source identifier (identifies sender and any conference 
contributors to the packet). The header includes other information, and the payload 
includes voice frames, compressed audio, video, real-time control and measurement 
data, or other real-time information. The timestamp reflects the sampling instant of the 
first byte of the first voice frame in the packet. A clock oscillator in the system of FIG. 3 
provides a suitably stable time base (i.e. a cycle master) for calculating this sampling 
instant time with sufficient accuracy to allow the delay-jitter handling block 371' and lost 
packet compensation block 381' to respond to delay, jitter, and out-of-order packets). 
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Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of generating a cycle record for each isochronous cycle of 
a first isochronous compliant network, wherein each cycle record includes a relative 
timing marker that indicates a timing of the real-time transport protocol data packet 
relative to a cycle master of the first isochronous compliant network as taught by 
Anandakumar the packet processing apparatus, and packet processing method of 
Ogawa in order tot provide necessary timing reference and guidelines for transmitting 
data to the destination device (as suggested by Anandakumar, paragraph 0227). Known 
work in one field of endeavor may prompt variations of it for use in either the same field 
or a different one based on design incentives or other market forces/market place 
incentives if the variations are predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
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real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Ogawa does not explicitly a IEEE-1394 compliant network, 

Ben-Dor in the same or similar field of endeavor teaches a first IEEE-1394 
compliant network, (paragraph 0081, 0110, 0012, 0226 cycle_offset 8: This field 
represents an offset to be added to the transmit time on the IEEE-1394 bus and 
inserted in the SYT and/or SPH field within a CIP (Common Isochronous Packet) 
based isochronous packet, bused on the CIP field. Cip 2: This field specifies if the 
current transmit time plus cycle offset should be inserted into the SYT field and/or 
SPH fields on a CIP based packet. The cycle offset is added to the cycle count field 
within IEEE-1934 cycle time. 00b = Do not modify SYT or SPH fields. 01b = Insert 
transmit cycle time plus off- set into the SYT field 10b = Insert transmit cycle time plus 
off- set into the SPH field 11b = Insert transmit cycle time plus off- set into both the 
SYT and SPH fields. The cycle offset field is IEEE-1394 specific and represents the 
cycle offset (from the local bus cycle count) of the actual transmit time from the 
SYT/SPH fields in the Common Isochronous Packet (CIP) used by IEEE-1394 A/V 
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devices. This field allows the network host to manage "presentation" times of data over 
IEEE-1394, even though the network host is not aware of the local IEEE-1394 cycle 
count. The absolute_cycle_time field represents the actual transmit time of the 
isochronous data on the IEEE-1394 local bus. This field allows the network host to 
synchronize its internal cycle count (in software) with the IEEE-1394 cycle count. The 
RPS may choose to throttle the data based on retrieval bandwidth using protocols such 
as RSVP or RTP or QOS Network services). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a IEEE-1394 compliant network as taught by Ben-Dor 
the packet processing apparatus, and packet processing method of Ogawa in order tot 
provide necessary timing reference and guidelines for transmitting data to the 
destination device (as suggested by Ben-Dor, paragraph 0226). Known work in one field 
of endeavor may prompt variations of it for use in either the same field or a different one 
based on design incentives or other market forces/market place incentives if the 
variations are predictable to one of ordinary skill in the art. 

Regarding claim 64 and 69 Ogawa teaches the real-time transport protocol data 
payload comprises one or more isochronous (I394) cycle records (See Section 4.1). 

Regarding claim 65 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 68 Ogawa teaches the receiving circuit is further configured to 
parse the one or more isochronous data packets (I394) from each received real-time 
transport protocol data packet (See sections 4 and 4.1). 
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4. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ogawa 
et al. (Design and implementation of DV based video over RTP. Proc. Packet 
Video2000, 2000), hereinafter Ogawa, Andandakumar and Craft as applied to claim 1 , 
above and further in view of Saito et al., hereinafter Saito, (US6523696). 

Regarding claim 12, Ogawa discloses all the subject matter of the claimed 
invention of claims 1 with the exception of each IEEE 1394 isochronous data packet 
includes an IEEE 1394 data payload formatted according to an IEC 61883-1 compliant 
Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61 883 (see Saito et al. column 38 line 2). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method of Ogawa in order tot 
provide necessary rules and guidelines for transmitting data (see Saito column 38 line 
5-10 and column 39 line 3-12). 

5. Claims 13, 29-31, 33-35, 38-46, 48-50 and 53-61 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Ogawa et al. (Design and implementation of DV 
based video over RTP. Proc. Packet Video2000, 2000), hereinafter Ogawa in view of 
Andandakumar et al. (US PAT PUB 2004/0252701, hereinafter Anandakumar) and 
Craft et al. (US PAT PUB 2007/0067497, hereinafter Craft). 
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Regarding claim 13, Ogawa teaches a Packet processing apparatus, and packet 
processing method comprising: a. a packetizing one or more data streams into 
isochronous data packets; b. encapsulating one or more isochronous data packets 
according to a real- time transport protocol to form a real-time transport protocol data 
packet; and c. sending the real-time transport protocol data packets from a transmitting 
device to a receiving device over a non-isochronous compliant network (sections 4-4.1, 
we implemented IP based DV video transmission system called DV Transport 
System(DVTS) using DV/RTP[5][6]. The overview of the DVTS is shown in Fig. 2. The 
system consists of a Pentium based PC with FreeBSD as an operating system, 
IEEE1394 device driver and interface^], and DV/RTP stream sender and receiver 
application. Both DV/RTP sender and receiver PC have an IEEE1394 interface on the 
PCI bus. The camcorder connected DV/RTP sender side (Shown in the left side of Fig. 
2) creates IEEE1394 encapsulated DV packet stream. The sender application receives 
the DV stream via PCI IEEE1394 interface card, encapsulates the DV packet of 
IEEE1394 into RTP, and transmits it to the IP network. The receiver application obtains 
the IEEE1394 DV packets by reconstructing DV data received using RTP. IEEE1394 
header is attached to the reconstructed DV/IEEE1394 packet and transferred to the DV 
recorder deck via PCI IEEE1394 interface card (Shown in the right side of Fig. 2). The 
DV recorder deck displays the DV data on the connected display. The DV system we 
implemented has the advantage that the system can be configured only with highly 
available standard PCI based PC compatibles, consumer DV camcorder and DV VCR 
equipment having IEEE1394 interface. In order to use consumer DV devices equipped 
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with IEEE1394 interface, we designed and implemented an IEEE1394 device driver on 
FreeBSD 3.3[7]. IEEE1394 high speed serial bus system is designed for a packet based 
shared media computer bus system. The network bandwidth is logically specified from 
100Mbps to 3.2Gbps. The goal of IEEE1394 is to integrate and observe various 
interface and cable specification into only single bus (cable) system, i.e. storage device 
interface instead of SCSI and IDE, peripheral of parallel and serial, network of ethernet, 
processor interconnect of VME and also RCA cable of audio and visual equipment. 
Heterogeneous speed devices can be connected within a single IEEE1394 physical 
network, which enables devices are made at the appropriate cost. Three types of 
transmission mode is provided by IEEE1394; 1)isochronous stream mode for QoS 
which provides especially strict packet jitter and guaranteed bandwidth without reliable 
communication, 2) asynchronous stream for best effort without reliability, and 
3)asynchronous request for the reliable communication. Data timing in IEEE1394 is 
shown in Fig 3. Every packet transmission action is brought with 8 kHz time slice whose 
value corresponds to the fairness unit in the IEEE1394 system. The 8kHz time slice unit 
is also divided into 6144 time slot for bandwidth management. Isochronous stream 
transmission would be done by taking the number of time slot the sender requires first, 
sending a packet whose size is smaller than the time slot at every 8kHz fairness unit. 
Therefore, the packet jitter of the isochronous stream mode is suppressed in the order 
of 8kHz (125 micro second), and the condition might be enough for any jitter sensitive 
high quality packet video system. It is not easy for the legacy packet based shared 
network system to satisfy such conditions. However, every IEEE1394 LSI chip already 
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supports the isochronous stream mode on its hardware level, and the cost of a chip is 
less than $20. Consumer DV adopts IEEE1394 as its digital interface standard, 
although the isochronous stream mode does not ensure reliable communication. When 
sending DV stream on IEEE1394, the 80 bytes DIF blocks are aggregated to 
appropriate size, e.g. an IEEE1 394 packet of consumer SD DV stream consists of 6 DIF 
blocks. 8 bytes common isochronous information (CIP) header is prepended to 
aggregated DV packet). Ogawa teaches the transmitting device is coupled to a first 
isochronous compliant network and the receiving device is coupled to a second 
isochronous compliant network (see figure 2). Ogawa teaches the real-time transport 
protocol defines a real-time transport protocol header and a real-time transport protocol 
data payload for each real-time transport protocol data packet (see figure 1) 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 

Anandakumar in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction (paragraph 0227, sampling instant) corresponding to 
the receipt of a first isochronous cycle start transaction corresponding to the receipt of a 
first isochronous data packet (i.e. the sampling instant of the first byte of the first voice 
frame) included in a particular real-time transport protocol data packet (paragraph 0227, 
In connection with FIG. 9, RTP is useful for real-time data like interactive voice and 
video (i.e. isochronous compliant network). RTP services include payload type 
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identification, sequence number, time stamp, and synchronization source identifier 
(identifies sender and any conference contributors to the packet). The header includes 
other information, and the payload includes voice frames, compressed audio, video, 
real-time control and measurement data, or other real-time information. The timestamp 
reflects the sampling instant of the first byte of the first voice frame in the packet. A 
clock oscillator in the system of FIG. 3 provides a suitably stable time base (i.e. a cycle 
master) for calculating this sampling instant time with sufficient accuracy to allow the 
delay-jitter handling block 371' and lost packet compensation block 381' to respond to 
delay, jitter, and out-of-order packets). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet as taught by Anandakumar the packet processing 
apparatus, and packet processing method of Ogawa in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
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isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Regarding claim 29, Ogawa teaches apparatus to communicate data streams, 
the apparatus comprising: • a transmitting circuit (figure 2, DV/RTP sender and receiver 
PC ) configured to encapsulate one or more first isochronous data packets according to 
a real-time transport protocol, thereby forming a first real-time transport protocol data 
packet, and to transmit the first real-time transport protocol data packets (Section 4, 
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IEEE1394 device driver and interface^], and DV/RTP stream sender and receiver 
application. Both DV/RTP sender and receiver PC have an IEEE 1394 interface on the 
PCI bus. The camcorder connected DV/RTP sender side) creates IEEE1394 
encapsulated DV packet stream. The sender application receives the DV stream via 
PCI IEEE1394 interface card, encapsulates the DV packet of IEEE1394 into RTP, and 
transmits it to the IP network); a receiving circuit (figure 2, DV/RTP sender and receiver 
PC) configured to receive a second real-time transport protocol data packet, and to de- 
encapsulate the received second real-time transport protocol data packets into one or 
more second isochronous data packets (Section 4, The receiver application obtains the 
IEEE1394 DV packets by reconstructing DV data received using RTP. IEEE1394 
header is attached to the reconstructed DV/IEEE1394 packet and transferred to the DV 
recorder deck via PCI IEEE1394 interface card). Ogawa teaches the real-time transport 
protocol defines a real-time transport protocol header and a real-time transport protocol 
data payload for each real-time transport protocol data packet (see figure 1). 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 

Anandakumar in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction (paragraph 0227, sampling instant) corresponding to 
the receipt of a first isochronous cycle start transaction corresponding to the receipt of a 
first isochronous data packet (i.e. the sampling instant of the first byte of the first voice 
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frame) included in a particular real-time transport protocol data packet (paragraph 0227, 
In connection with FIG. 9, RTP is useful for real-time data like interactive voice and 
video (i.e. isochronous compliant network). RTP services include payload type 
identification, sequence number, time stamp, and synchronization source identifier 
(identifies sender and any conference contributors to the packet). The header includes 
other information, and the payload includes voice frames, compressed audio, video, 
real-time control and measurement data, or other real-time information. The timestamp 
reflects the sampling instant of the first byte of the first voice frame in the packet. A 
clock oscillator in the system of FIG. 3 provides a suitably stable time base (i.e. a cycle 
master) for calculating this sampling instant time with sufficient accuracy to allow the 
delay-jitter handling block 371' and lost packet compensation block 381' to respond to 
delay, jitter, and out-of-order packets). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet as taught by Anandakumar the packet processing 
apparatus, and packet processing method of Ogawa in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
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design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 
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In regards to claim 30, Ogawa teaches the transmitting device is coupled to a 
first isochronous compliant network and the receiving device is coupled to a second 
isochronous compliant network (see figure 2). 

Regarding claim 31 Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network each comprise an IEEE 1394 compliant bus 
architecture (see figure 2 IEEE1394 bus). 

Regarding claim 33, Ogawa teaches the real-time transport protocol data 
payload comprises one or more isochronous (I394) cycle records (See Section 4.1). 

Regarding claim 34 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 35, Ogawa teaches each isochronous data packet comprises an 
IEEE 1394 isochronous data packet (See Section 4.1). 

Regarding claim 38, Ogawa teaches the transmitting circuit is further 
configured to packetize one or more data streams into the one or more isochronous 
data packets (See section 4). 

Regarding claim 39, Ogawa teaches the transmitting circuit is further 
configured to receive the one or more isochronous data packets from another device 
(See sections 4 and 4.1). 

Regarding claim 40 Ogawa teaches the receiving circuit is further configured to 
parse the one or more isochronous data packets (I394) from each received real-time 
transport protocol data packet (See sections 4 and 4.1). 
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Regarding claim 41 Ogawa teaches each real-time transport protocol data packet 
includes at least a portion of an isochronous cycle record (See Section 4.1). 

Regarding claim 42 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 43, Ogawa teaches a network of devices to communicate data 
streams, the network of devices comprising: a. a transmitting device configured to 
encapsulate one or more isochronous data packets according to a real-time transport 
protocol, thereby forming a real-time transport protocol data packet, and to transmit the 
real-time transport protocol data packets; b. a first isochronous compliant network 
coupled to the transmitting device; c. a receiving device configured to receive the real- 
time transport protocol data packets; d. a second isochronous compliant network 
coupled to the receiving device; and e. a network coupled to the first isochronous 
compliant network and the second isochronous compliant network to transmit the real- 
time transport protocol data packets from the transmitting device to the receiving device; 
a non-isochronous compliant network coupled to the receiving device; and Saito the 
same or similar fields of endeavor teaches the use of public network such as internet, 
and the ATM network exists between them (sections 4-4.1, we implemented IP based 
DV video transmission system called DV Transport System(DVTS) using DV/RTP[5][6]. 
The overview of the DVTS is shown in Fig. 2. The system consists of a Pentium based 
PC with FreeBSD as an operating system, IEEE1394 device driver and interface^], and 
DV/RTP stream sender and receiver application. Both DV/RTP sender and receiver PC 
have an IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender 
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side (Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet 
stream. The sender application receives the DV stream via PCI IEEE1394 interface 
card, encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP 
network. The receiver application obtains the IEEE1394 DV packets by reconstructing 
DV data received using RTP. IEEE1394 header is attached to the reconstructed 
DV/IEEE1394 packet and transferred to the DV recorder deck via PCI IEEE1394 
interface card (Shown in the right side of Fig. 2). The DV recorder deck displays the DV 
data on the connected display. The DV system we implemented has the advantage that 
the system can be configured only with highly available standard PCI based PC 
compatibles, consumer DV camcorder and DV VCR equipment having IEEE1394 
interface. In order to use consumer DV devices equipped with IEEE1394 interface, we 
designed and implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 
high speed serial bus system is designed for a packet based shared media computer 
bus system. The network bandwidth is logically specified from 100Mbps to 3.2Gbps. 
The goal of IEEE1394 is to integrate and observe various interface and cable 
specification into only single bus (cable) system, i.e. storage device interface instead of 
SCSI and IDE, peripheral of parallel and serial, network of ethernet, processor 
interconnect of VME and also RCA cable of audio and visual equipment. 
Heterogeneous speed devices can be connected within a single IEEE1394 physical 
network, which enables devices are made at the appropriate cost. Three types of 
transmission mode is provided by IEEE1394; 1)isochronous stream mode for QoS 
which provides especially strict packet jitter and guaranteed bandwidth without reliable 
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communication, 2) asynchronous stream for best effort without reliability, and 
3)asynchronous request for the reliable communication. Data timing in IEEE1394 is 
shown in Fig 3. Every packet transmission action is brought with 8 kHz time slice whose 
value corresponds to the fairness unit in the IEEE1394 system. The 8kHz time slice unit 
is also divided into 6144 time slot for bandwidth management. Isochronous stream 
transmission would be done by taking the number of time slot the sender requires first, 
sending a packet whose size is smaller than the time slot at every 8kHz fairness unit. 
Therefore, the packet jitter of the isochronous stream mode is suppressed in the order 
of 8kHz (125 micro second), and the condition might be enough for any jitter sensitive 
high quality packet video system. It is not easy for the legacy packet based shared 
network system to satisfy such conditions. However, every IEEE1394 LSI chip already 
supports the isochronous stream mode on its hardware level, and the cost of a chip is 
less than $20. Consumer DV adopts IEEE1394 as its digital interface standard, 
although the isochronous stream mode does not ensure reliable communication. When 
sending DV stream on IEEE1394, the 80 bytes DIF blocks are aggregated to 
appropriate size, e.g. an IEEE1 394 packet of consumer SD DV stream consists of 6 DIF 
blocks. 8 bytes common isochronous information (CIP) header is prepended to 
aggregated DV packet). Ogawa teaches the real-time transport protocol defines a real- 
time transport protocol header and a real-time transport protocol data payload for each 
real-time transport protocol data packet (see figure 1 ). 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
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to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 

Anandakumar in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction (paragraph 0227, sampling instant) corresponding to 
the receipt of a first isochronous cycle start transaction corresponding to the receipt of a 
first isochronous data packet (i.e. the sampling instant of the first byte of the first voice 
frame) included in a particular real-time transport protocol data packet (paragraph 0227, 
In connection with FIG. 9, RTP is useful for real-time data like interactive voice and 
video (i.e. isochronous compliant network). RTP services include payload type 
identification, sequence number, time stamp, and synchronization source identifier 
(identifies sender and any conference contributors to the packet). The header includes 
other information, and the payload includes voice frames, compressed audio, video, 
real-time control and measurement data, or other real-time information. The timestamp 
reflects the sampling instant of the first byte of the first voice frame in the packet. A 
clock oscillator in the system of FIG. 3 provides a suitably stable time base (i.e. a cycle 
master) for calculating this sampling instant time with sufficient accuracy to allow the 
delay-jitter handling block 371' and lost packet compensation block 381' to respond to 
delay, jitter, and out-of-order packets). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
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transport protocol data packet as taught by Anandakumar the packet processing 
apparatus, and packet processing method of Ogawa in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
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suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Regarding claim 44 Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network each comprise an IEEE 1394 compliant bus 
architecture (see figure 2 IEEE1394 bus). 

Regarding claim 48 Ogawa teaches each real-time transport protocol data packet 
includes at least a portion of an isochronous cycle record (See Section 4.1). 

Regarding claim 49 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 

Regarding claim 45, Ogawa teaches the non-isochronous compliant network 
comprises an Internet Protocol network (see figure 2). 

Regarding claim 46 Ogawa teaches the Internet Protocol network comprises an 
Ethernet/Internet Protocol network (see Abstract). 

Regarding claim 55 Ogawa teaches the receiving circuit is further configured to 
parse the one or more isochronous data packets (I394) from each received real-time 
transport protocol data packet (See sections 4 and 4.1). 

Regarding claim 56 Ogawa teaches the real-time transport protocol data payload 
comprises one or more isochronous (I394) cycle records (See Section 4.1). 

Regarding claim 57 Ogawa teaches each of the one or more isochronous cycle 
records comprises zero or more isochronous data packets (See Section 4.1). 
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Regarding claim 50 Ogawa teaches each isochronous data packet comprises an 
IEEE 1394 isochronous data packet (See Section 4.1). 

Regarding claim 53 Ogawa teaches the transmitting circuit is further 
configured to packetize one or more data streams into the one or more isochronous 
data packets (See section 4). 

Regarding claim 54 Ogawa teaches the transmitting circuit is further 
configured to receive the one or more isochronous data packets from another device 
(See sections 4 and 4.1). 

Regarding claim 58, Ogawa teaches a method of communicating data streams, 
the method comprising: a. packetizing one or more data streams into IEEE 1394 
compliant isochronous data packets; b. encapsulating one or more IEEE 1394 
compliant isochronous data packets according to a real-time transport protocol to form a 
real-time transport protocol data packet; and c. sending the real-time transport protocol 
data packets from a transmitting device to a receiving device over a non-isochronous 
compliant network (sections 4-4.1, we implemented IP based DV video transmission 
system called DV Transport System(DVTS) using DV/RTP[5][6]. The overview of the 
DVTS is shown in Fig. 2. The system consists of a Pentium based PC with FreeBSD as 
an operating system, IEEE1394 device driver and interface^], and DV/RTP stream 
sender and receiver application. Both DV/RTP sender and receiver PC have an 
IEEE1394 interface on the PCI bus. The camcorder connected DV/RTP sender side 
(Shown in the left side of Fig. 2) creates IEEE1394 encapsulated DV packet stream. 
The sender application receives the DV stream via PCI IEEE1394 interface card, 
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encapsulates the DV packet of IEEE1394 into RTP, and transmits it to the IP network. 
The receiver application obtains the IEEE1394 DV packets by reconstructing DV data 
received using RTP. IEEE1394 header is attached to the reconstructed DV/IEEE1394 
packet and transferred to the DV recorder deck via PCI IEEE1394 interface card 
(Shown in the right side of Fig. 2). The DV recorder deck displays the DV data on the 
connected display. The DV system we implemented has the advantage that the system 
can be configured only with highly available standard PCI based PC compatibles, 
consumer DV camcorder and DV VCR equipment having IEEE1394 interface. In order 
to use consumer DV devices equipped with IEEE1394 interface, we designed and 
implemented an IEEE1394 device driver on FreeBSD 3.3[7]. IEEE1394 high speed 
serial bus system is designed for a packet based shared media computer bus system. 
The network bandwidth is logically specified from 100Mbps to 3.2Gbps. The goal of 
IEEE1394 is to integrate and observe various interface and cable specification into only 
single bus (cable) system, i.e. storage device interface instead of SCSI and IDE, 
peripheral of parallel and serial, network of ethernet, processor interconnect of VME and 
also RCA cable of audio and visual equipment. Heterogeneous speed devices can be 
connected within a single IEEE1394 physical network, which enables devices are made 
at the appropriate cost. Three types of transmission mode is provided by IEEE1394; 
1)isochronous stream mode for QoS which provides especially strict packet jitter and 
guaranteed bandwidth without reliable communication, 2) asynchronous stream for best 
effort without reliability, and 3)asynchronous request for the reliable communication. 
Data timing in IEEE1394 is shown in Fig 3. Every packet transmission action is brought 
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with 8 kHz time slice whose value corresponds to the fairness unit in the IEEE1394 
system. The 8kHz time slice unit is also divided into 6144 time slot for bandwidth 
management. Isochronous stream transmission would be done by taking the number of 
time slot the sender requires first, sending a packet whose size is smaller than the time 
slot at every 8kHz fairness unit. Therefore, the packet jitter of the isochronous stream 
mode is suppressed in the order of 8kHz (125 micro second), and the condition might 
be enough for any jitter sensitive high quality packet video system. It is not easy for the 
legacy packet based shared network system to satisfy such conditions. However, every 
IEEE1394 LSI chip already supports the isochronous stream mode on its hardware 
level, and the cost of a chip is less than $20. Consumer DV adopts IEEE1394 as its 
digital interface standard, although the isochronous stream mode does not ensure 
reliable communication. When sending DV stream on IEEE1394, the 80 bytes DIF 
blocks are aggregated to appropriate size, e.g. an IEEE1394 packet of consumer SD 
DV stream consists of 6 DIF blocks. 8 bytes common isochronous information (CIP) 
header is prepended to aggregated DV packet). Ogawa teaches the real-time transport 
protocol defines a real-time transport protocol header and a real-time transport protocol 
data payload for each real-time transport protocol data packet (see figure 1). 

Ogawa does not explicitly teach a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet. 
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Anandakumar in the same or similar field of endeavor teaches a value of the 
isochronous cycle start transaction (paragraph 0227, sampling instant) corresponding to 
the receipt of a first isochronous cycle start transaction corresponding to the receipt of a 
first isochronous data packet (i.e. the sampling instant of the first byte of the first voice 
frame) included in a particular real-time transport protocol data packet (paragraph 0227, 
In connection with FIG. 9, RTP is useful for real-time data like interactive voice and 
video (i.e. isochronous compliant network). RTP services include payload type 
identification, sequence number, time stamp, and synchronization source identifier 
(identifies sender and any conference contributors to the packet). The header includes 
other information, and the payload includes voice frames, compressed audio, video, 
real-time control and measurement data, or other real-time information. The timestamp 
reflects the sampling instant of the first byte of the first voice frame in the packet. A 
clock oscillator in the system of FIG. 3 provides a suitably stable time base (i.e. a cycle 
master) for calculating this sampling instant time with sufficient accuracy to allow the 
delay-jitter handling block 371' and lost packet compensation block 381' to respond to 
delay, jitter, and out-of-order packets). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a value of the isochronous cycle start transaction 
corresponding to the receipt of a first isochronous cycle start transaction corresponding 
to the receipt of a first isochronous data packet included in a particular real-time 
transport protocol data packet as taught by Anandakumar the packet processing 
apparatus, and packet processing method of Ogawa in order tot provide necessary 



Application/Control Number: 10/814,848 Page 40 

Art Unit: 2476 

tinning reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Anandakumar implicitly teaches a relative timing marker that indicates a timing of 
the real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network but does not explicitly teach a relative timing marker that 
indicates a timing of the real-time transport protocol data packet relative to a cycle 
master of the first isochronous compliant network. 

Craft in the same or similar field of endeavor teaches The RTP header contains a 
timestamp (i.e. relative timing marker) that indicates the relative times at which the AV 
data is packetized (i.e. a cycle master) by the audio/video interface 666 (paragraph 
0105). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the steps of a relative timing marker that indicates a timing of the 
real-time transport protocol data packet relative to a cycle master of the first 
isochronous compliant network as taught by Craft the packet processing apparatus, and 
packet processing method of Ogawa and Anandakumar, in order tot provide necessary 
timing reference and guidelines for transmitting data to the destination device (as 
suggested by Anandakumar, paragraph 0227). Known work in one field of endeavor 
may prompt variations of it for use in either the same field or a different one based on 
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design incentives or other market forces/market place incentives if the variations are 
predictable to one of ordinary skill in the art. 

Regarding claim 59 Ogawa teaches the first isochronous compliant network and 
the second isochronous compliant network each comprise an IEEE 1394 compliant bus 
architecture (see figure 2 IEEE1394 bus). 

Regarding claims 60, Ogawa teaches the non-isochronous compliant network 
comprises an Internet Protocol network (see figure 2). 

Regarding claims 61 Ogawa teaches the Internet Protocol network comprises an 
Ethernet/Internet Protocol network (see Abstract). 

6. Claims 26, 36 and 51 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Ogawa et al. (Design and implementation of DV based video over RTP. Proc. 
Packet Video2000, 2000), hereinafter Ogawa, and in view of Andandakumar et al. (US 
PAT PUB 2004/0252701 , hereinafter Anandakumar) and Craft et al. (US PAT PUB 
2007/0067497, hereinafter Craft)and further in view of Saito et al., hereinafter Saito, 
(US6523696). 

Regarding claim 26, Ogawa discloses all the subject matter of the claimed 
invention of claims 1 and 15 with the exception of each IEEE 1394 isochronous data 
packet includes an IEEE 1394 data payload formatted according to an IEC 61883-1 
compliant Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61883 (see Saito et al. column 38 line 2). 
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Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method/system of Ogawa in order 
tot provide necessary rules and guidelines for transmitting data (see Saito column 38 
line 5-10 and column 39 line 3-12). 

Regarding claims 36 and 51, Ogawa discloses all the subject matter of the 
claimed invention of claims 29, 43 and 58 with the exception of each IEEE 1394 
isochronous data packet includes an IEEE 1394 data payload formatted according to an 
IEC 61883-1 compliant Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61 883 (see Saito et al. column 38 line 2). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method/system of Ogawa, in order 
tot provide necessary rules and guidelines for transmitting data (see Saito column 38 
line 5-10 and column 39 line 3-12). 

7. Claim 66 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ogawa 
et al. (Design and implementation of DV based video over RTP. Proc. Packet 
Video2000, 2000), hereinafter Ogawa, and in view of Andandakumar et al. (US PAT 
PUB 2004/0252701, hereinafter Anandakumar), Craft et al. (US PAT PUB 
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2007/0067497, hereinafter Craft), Ben-Dor et al. (US PAT PUB 2002/0141418, 
hereinafter Ben-Dor) and further in view of Saito et al., hereinafter Saito, (US6523696). 

Regarding claims 66, Ogawa discloses all the subject matter with the exception 
of each IEEE 1394 isochronous data packet includes an IEEE 1394 data payload 
formatted according to an IEC 61883-1 compliant Common Isochronous Protocol (CIP). 

Saito et al. from the same or similar fields of endeavor teaches the use of 
encapsulation of the IEC 61 883 (see Saito et al. column 38 line 2). 

Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to use the encapsulation of the IEC 61883 as taught by Saito et al in the 
packet processing apparatus, and packet processing method/system of Ogawa in order 
tot provide necessary rules and guidelines for transmitting data (see Saito column 38 
line 5-10 and column 39 line 3-12). 

Response to Arguments 
8. Applicant's arguments see pages 1 1 -1 7 of the Remarks section, filed 7/1 0/2009, 
with respect to the rejections of the claims have been fully considered and are moot in 
view of new ground of rejections presented in this office action. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to SALMAN AHMED whose telephone number is 
(571)272-8307. The examiner can normally be reached on 9:00 am - 5:30 pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ayaz Sheikh can be reached on (571 )272-3795. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Salman Ahmed/ 

Primary Examiner, Art Unit 2476 



